跳到主要内容

Understanding Stragglers in Large Model Training Using What-if Analysis

简介​

探究大语言模型的混合并行训练过程中的慢节点的影响和原因。 并使用 What-if 方法分析如何这些慢节点不存在，理论完成任务的时间是多少？

Profile 方法​

一个假设：调度上保证了通信资源是无竞争的，因此通信不会导致慢节点 Trace信息：包括 Dense 和 MoE 的模型，任务都是大于 128 GPUs 的任务。 训练框架基于 Megatron-LM 修改，使用 DP, PP, TP, CP 并行策略 使用 NDTimeline 采样 10% 的训练步骤，记录如下数据：

  1. PP 中 stage 的前向和反向传播时间（计算时间）
  2. PP 中的 P2P 通信时间
  3. DP 的通信时间 注：看起来好像只支持了 PP + DP 的训练方式

What-if 方法分析​

需要确定算子间的依赖和算子的执行时延才能分析理论值。

对于算子执行时延：计算时间取全部的平均时间，通信时间取中位数。计算的滞后大多由计算不平衡引起，因此用平均符合重平衡计算，通信的滞后大多由网卡或交换机的 flapping 引起。

对于算子直接的执行依赖：文章直接按照 DP PP 的场景来讨论，不具有通用性。

一些观察​

  1. 大作业（通常比理论慢3倍）由少部分 3% 的节点影响，怀疑是硬件问题或错误配置。
  2. 慢节点不是只有几步特别慢，大多数时间都比较慢。
  3. 计算操作通常会比通信操作更容易慢。

一些分析​

  1. PP 并行计算负载分配不均，这个影响 PP 组的完成时间。（看起来他们没解决）
  2. 训练长上下文的任务，序列长度的不平衡，会影响 DP 组完成时间。（重新按照长度分配）
  3. Python 的 GC 机制。（Megatron-LM似乎可以实现手动同步GC）